perm filename MAIL.PRO[DLN,MRC]6 blob
sn#345167 filedate 1978-03-27 generic text, type C, neo UTF8
COMMENT ā VALID 00008 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Dialnet memo #5
C00004 00003 INTRODUCTION
C00009 00004 SYNTAX
C00014 00005 GOALS AND NON-GOALS
C00016 00006 MAIL FIELDS
C00019 00007 MAIL COMMANDS
C00023 00008 MAIL COMMANDS (continued)
C00025 ENDMK
Cā;
Dialnet memo #5
SAILON down the muddy Mississippi
Dialnet Protocols
(or, the Protocols of DIAL)
MAIL Protocols
Mark Crispin
3/27/78
These protocols are being developed as part of the Dialnet project at the
Stanford University Artificial Intelligence Laboratory supported by NSF grant
MCS 77-02080 with John McCarthy as Principal Investigator. The project is
described in a paper available online at ARPAnet host SU-AI as
DIALNE.MEM[DLN,MRC] (Dialnet Memo #1).
This is MAIL.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
INTRODUCTION
The host-host protocol described in Dialnet memo #2 documents a mechanism
for hosts to establish an error-free data link between two cooperating
processes. This protocol, however, is insufficient to specify communication
between dissimilar mail processes in different hosts. The processes must have
some agreement as to the format messages should be in, and how mail addressing
and delivery should be handled.
The ARPAnet implements mail as part of the file transfer protocol. This
has some advantages and disadvantages. A short-term advantage of this form of
mailing is that it is relatively simple to implement and interface to an
existing mail system if the current mail system already uses something
approaching the standard format.
In the long term, however, many problems have arisen as increasingly, more
varieties of mail formats have appeared and more hairy mail reading programs
have been written to parse these formats. It would be short-sighted to assume
that this would not happen with Dialnet mail as well. In addition, the ARPAnet
mail formats leave much to be desired.
First, they are in the format of a business memorandum, leading many to the
assumption that a business memorandum was the proper format for message headers
to take.
Second, too much flexibility was allowed in the formats of various items,
with the unfortunate result that too many esoteric varieties of mail commands
ensued, and many trivial arguments over highly esoteric matters developed.
Dialnet mail avoids the problem with multiple formats of message headers by
eliminating them entirely. Instead, messages are sent using a mail protocol.
Each host is only required to implement what parts of the protocol they require
after a certain common minimum subset. If a host wishes to have a message
heading (as well it might, since valuable information such as whom the message
was from is contained therein), it may generate a header in any format.
Keeping this in mind, a method of expressing such information in a clearly
unambiguous and readily machine-parsable way was sought. The LISP syntax of
S-expressions was chosen, due to its extreme versatility.
In the mail protocol, the user sends S-expressions as commands to the
server, which replies in turn using S-expressions. No actual LISP evaluating is
actually done; all that is needed is a "LISP reader" which can recognize an
S-expression and be able to distinguish the CAR and CDR of an expression.
For those unfamiliar with LISP, a brief introduction to the syntax is on
the next page. It is not intended to be a description of LISP syntax, but
rather the "LISPese" syntax used by Dialnet mail.
SYNTAX
The mail protocol consists of an interchange of S-expressions, which are
things inside balanced parenthesis. Parenthesis are special characters in all
cases. In order for them to be included in text, they must be quoted with a
slash (/) character. Hence slash is a special character as well.
Newline is represented by an 012 byte. This is distinct from the "line
feed" character, which does not exist in the mail protocol.
The character set which is legal in the mail protocol consists of all the
printing characters in the 1968 ASCII character set including space (in other
words, the characters whose ASCII value is between 040 and 176) and newline. In
particular, rubout and the "control" characters (some of which are used for text
formatting on some systems) are not part of the protocol and should not be used.
There is no guarantee that the server will interpret these characters in the way
the user intended.
If for some reason "control" characters MUST be sent, it should be noted
that line feed must be quoted since otherwise it would be interpreted as
newline. Again, servers are under no obligation to implement "control"
characters.
There are no other special characters. In particular, whitespace and
newlines within an S-expression are treated as significant in many places. In
non-textual situations, such as delimiting between atomic values, a single
whitespace or newline is required and further whitespace/newlines are
superfluous and should be ignored. However, while mail servers should be
prepared to ignore superfluous whitespace or newlines, it is strictly speaking a
violation of protocol to send superfluous whitespace or newlines.
Some LISP terms need to be defined for the non-LISP user to make the rest
of this document clearer. Within an S-expression, there can be atoms or other
S-expressions. An atom is an indivisible "word". The other S-expressions are
called "lists", as they are not evaluated further.
The CAR of an S-expression or list is the first atom in the list. The CDR
is what remains of the S-expresssion after the CAR has been removed. These two
terms are sometimes combined; the second element of the list is the CAR of the
CDR or the CADR; the third element is the CAR of the CDR of the CDR or CADDR,
etc.
EXAMPLES:
1. FOO is an atom
2. (FOO BAR) is a list
3. (FOO BAR GARPLY) is a list
4. (FOO BAR (BAZ GARPLY)) is a list
5. FOO is the CAR of #2, #3, and #4
6. (BAR (BAZ GARPLY)) is the CDR of #4
7. BAR is the CAR of #6
8. (BAZ GARPLY) is the CDR of #6
9. FOO/ BAR is an atom!!
GOALS AND NON-GOALS
1. To avoid repeating the mistakes of ARPAnet mail.
2. To have a system that is simple to implement.
3. To establish strict mail formats with no ambiguity of format, to prevent the
proliferation of mail header formats which has occured in the ARPAnet.
4. To allow the mail sender complete freedom in what is included in the actual
body of the mail message.
5. To abolish mail headers as they exist in current mail systems entirely.
6. To replace the information formerly contained in the mail header with a mail
protocol negotiation.
The following are currently non-goals. It is felt that there is no
justification at the present time to consider these matters.
1. Compatability with ARPAnet mail.
2. Message security or encryption. This may happen later.
3. Explicit forwarding.
4. Detection and deletion of duplicate copies of a message or of mail loops.
MAIL FIELDS
*** NOTE ***
In all mail fields, it is STRONGLY SUGGESTED that either upper or lower
case be accepted, and that lower case be converted to upper case for machine-
reading purposes. In addition, the official case for protocol commands is upper
case; however, a server must not depend upon only receiving upper case. A
server that fails to do case-independent matching is bound to encounter problems
in interfacing with other systems.
The fields or arguments to a mail protocol command are one of the
following:
ADDRESS -- an atom or list which specifies a valid machine-readable
mail address on the host in question.
HOST-IDENTIFICATION -- either phone-number or a list whose CAR is
phone-number and whose CADR is host-name.
HOST-NAME -- an atom which specifies the official host name as kept on
record by the Dialnet implementors.
MESSAGE-TEXT -- a text string consisting of the actual text of the
message.
PHONE-NUMBER -- a dialup phone number in the form of a string of
digits.
SUBJECT-TEXT -- an optional text string used as a one-line "topic" of
the message.
TEXT -- a data type (see SUBJECT-TEXT and MESSAGE-TEXT) which is
completely quoted. TEXT outwardly looks like a list in that
there are parentheses at each end, and parentheses and slashes
must be quoted with slash; however, whitespace and new lines are
significant and are not converted to something else by the mail
process.
MAIL COMMANDS
The commands on these pages are the more important commands of the mail
protocol which all servers are expected to implement.
For all mail commands, the reply (FAILED) is used to indicate a command
that failed due to some internal bug on the part of the server, for such things
as string space exhausted or the like. This code is NOT intended to be used to
indicate a user error.
I. (TO address)
This is the most important command in the mail protocol, and the only
required one. It specifies to whom the message is to be sent. The address must
be a legal address for the server site; ie, it must be machine-readable as
opposed to a "human" address.
Examples:
(TO MRC)
(TO Network/ Wizard)
Replies:
(OK)
The address has been accepted. More destinations may be specified for
this message.
(OK-NO-MORE)
The address has been accepted, but no more destinations may be
specified for this message.
(UNKNOWN)
The address has been rejected; there is no known destination at this
site with that address.
(ILLEGAL)
The address is in illegal format for this site.
II. (FROM address host-identification)
This command specifies the origin of the message. The address must be a
legal address for the user site's mail server; ie, it must be machine-readable.
The address in this command is the default for the SENDER and REPLY-TO
addresses. It should be noted that many sites may not wish to implement SENDER
and REPLY-TO. This means that FROM is required if any origin is specified at
all, and that it should specify a reasonable origin and reply address.
Examples:
(FROM MRC 415-497-1234)
(FROM DIALNET-HACKER (415-497-4321 SU-AI))
Replies:
(OK)
The command was accepted. This is the only legal response.
MAIL COMMANDS (continued)
III. (SUBJECT subject-text)
This command specifies a subject text for the message. It is used to
provide a short topic for the message for the reference or filing purposes of
the eventual message reader.
Examples:
(SUBJECT (Suggested addition to the MAIL protocol))
(SUBJECT (In reply to your message about the MAIL protocol))
Replies:
(OK)
The command was accepted. This is the only legal response.
IV. (MESSAGE message-text)
This command specifies the text body of the message.
Example:
(MESSAGE (It has been suggested that the MAIL protocol be enhanced
to make the phase of the moon be a required item in all
messages. It is felt that this item is very important
and all user and server programs will be expected to
implement this by next Tuesday.
))
Replies:
(OK)
The command was accepted. This is the only legal response.